Electronic transactions based on deal forms

ABSTRACT

In the preferred computer system, the user is provided with a separate Internet-accessible entity referred to here as the “personal page.” A personal page, preferably, includes memory for storing information related to the user. For example, on his/her personal page the user indicates what he/she wishes to purchase, possibly along with other criteria associated with the purchase, such as, for example, a time that the purchase should take The user is provided with the ability to create personalized bidding rules that vendors that offer goods and services must respect. Vendors have the ability to specify similar criteria, which describe the goods and/or services they offer. Vendors can indicate, for example, the prices of their goods, times and places that their services are available, etc. Preferably, these specifications, called “vendor scripts,” are embodied in active software/data entities (agents) that traverse sites on the Internet visiting sites hosting users&#39; personal pages. Thus, preferably, vendor software/data agents (comprising vendor scripts) are the mobile, active elements in the system and purchasing requirements are stationary and more passive in comparison.

BACKGROUND OF THE INVENTION

In traditional e-commerce, a user electronically attaches to a vendor'sInternet Web site to make purchases. This most widely-used model isessentially an electronic catalog, in which goods and/or services arelisted by vendors and purchasers actively peruse. Operators of thesesites invest millions of dollars in advertising and brand building inorder to encourage users to visit their sites, thereby increasing thecosts of products since advertising costs must be passed on.

In traditional e-commerce, the user has limited power since he/she isforced by the structure of the marketplace to transact business with aspecific site. There are, however, sites that “look for” the best deal.Here, the user has more flexibility and is more empowered, but still isat the mercy of the site doing the searching. There is still a manualelement involved. Furthermore, the user may have to attach to anothersite to transact the purchase.

Another e-commerce technique is essentially a reverse auction, in whichthe user indicates a desired price and providers of goods and servicesvie to meet the price. Yet another model allows a user to requests anitem on a web site and the site sends the request to vendors in order toobtain the desired product. Bidding on Internet sites is also wellknown, e.g., eBay.com. Also, some sites allow users to design acustomized view (i.e., a Web page) of the site. Further, there arebusiness-to-business sites where businesses buy and sell products andservices. There are other e-commerce techniques (includingbusiness-to-business) as known in the art. What all these methods havein common is that they do not provide sufficient autonomy to users, whomust visit sites to make purchases. In current electronic business, theuser is not sufficiently empowered in the electronic world known as theInternet.

SUMMARY OF THE INVENTION

This invention applies to both commercial and consumer applications ofcomputer technology. Thus, users of the described system can be eitherconsumers purchasing goods and/or services for personal use orcommercial enterprises obtaining business-related goods and/or services.(In some embodiments, the term “user” can refer to a human being and/ora machine, such as a computer. In some embodiments “user” can refer to acorporation or other group of human beings. Similarly, the term “vendor”can refer to a human being or corporation or other group of humanbeings, and/or a computer or set of computers.)

In the preferred system, the user is provided with a separateInternet-accessible entity referred to here as the “personal page.” Apersonal page, preferably, includes memory for storing informationrelated to its user. For example, on his/her personal page, the userindicates what he/she wishes to purchase, possibly along with othercriteria associated with the purchase, such as, for example, a time thatthe purchase should take place. (In some implementations the personalpage can be used to specify what the user wants to sell.) For example, aconsumer wishing to purchase a service, such as a haircut, couldindicate that he/she wishes to obtain the services of a barber at aparticular time on a particular date, or more generally within aparticular time interval over a succession of dates (“Between 3 μm and 5μm Monday Or Wednesday next week”). Other criteria might include theplace that the goods or services are to be delivered, for example. Theuser is provided with the ability to create personalized bidding rulesthat vendors that offer goods and services (collectively known as“items” for sale) must respect. For example, the user may indicate thathe/she will accept the lowest price received within an hour, day, etc.Similarly, the user can also say that he/she will not accept a pricethat is greater than a specified amount, and/or the desired item shouldbe delivered no later than a given date/time.

A user's purchasing or buying requirements (“B.R.”) are stored onhis/her personal page. The meaning of B.R. (purchasing/buyingrequirements) is not limited to purchasing or buying, and may relate toother requirements stored in connection with a personal page, forexample, requests for service, information, advertisement, as well asother data.

Vendors have the ability to specify similar criteria, which describe thegoods and/or services they offer. Vendors can indicate, for example, theprices of their goods, times and places that their services areavailable, etc. Vendors, preferably, do not have personal pages on whichthe specification is done. Preferably, these specifications, called“vendor scripts,” are embodied in active software/data entities (agents)that traverse sites on the Internet visiting sites hosting users'personal pages. Thus, preferably, vendor software/data agents(comprising vendor scripts) are the mobile, active elements in thesystem and personal pages are stationary and more passive in comparison.Alternatively, vendor scripts may be stored on a personal pageassociated with a vendor. Also, alternatively, a personal page maycontain both B.R.'s and vendor scripts. Though B.R.'s (vendor scripts)are preferably translated to lower level language equivalents and thenstored on personal pages (vendor sites), we will continue to refer tothe translated equivalents as B.R.'s (vendor scripts) for simplicity.Users and vendors are preferably given the capability of entering,editing, deleting, activating, deactivating, and reactivating B.R.'s andvendor scripts using techniques known in the art.

In the preferred embodiment, vendors of various items send electronicrepresentatives (software agents, in the form of a script in anappropriate scripting language, for example) that visit personal pages.This electronic representative includes sufficient information tointerface with the user's B.R. on the personal page so as to completetransactions if a compatible match is found. (Also, if permitted by theuser, electronic representatives of the vendors may suggest alternativeproducts.) In this implementation, instead of forcing a user to purchaseitems at vendors' sites, as is now mostly the case, the vendors “come”to the user and bid in accordance with the user's bidding rules.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A illustrates the overall architecture of one preferredembodiment;

FIG. 1B illustrates the overall preferred organization where the B.R.'sare stationary and the vendor scripts are mobile components;

FIG. 2 illustrates computer steps of entering requirements (B.R.'s) andvendor scripts using electronic input forms;

FIG. 3 illustrates the steps associated with voice input of B.R.'s(vendor scripts);

FIG. 4 illustrates the steps of creating a purchase (vendor) form;

FIG. 5 illustrates how B.R.'s specified in a scripting language arehandled;

FIG. 6 illustrates how vendor scripts specified in a scripting languageare handled;

FIG. 7 illustrates system process handling checking newly arrived vendorforms for compatibility with purchase form sets;

FIG. 8 illustrates the steps of deciding compatibility of vendor andpurchase forms;

FIG. 9 illustrates checking form attributes for compatibility using acompatibility dictionary;

FIG. 10 illustrates software supporting bidding in connection with auser who desires to find a lowest priced item within a given timeperiod;

FIG. 11 illustrates the preferred processing for closing a deal betweena buyer and seller who require verification of agreement;

FIG. 12 illustrates providing advertisement to a personal page;

FIGS. 13, 14A and 14B illustrate personal page applications usingdynamic geographical location input data;

FIGS. 15A and 15B illustrate interaction with a user for substantiallyoptimal purchase selection;

FIGS. 16A and 16B illustrate an example of how the system determines asubstantially optimal purchase for two slots (items);

FIG. 16C illustrates pseudocode of the two-slot example shown in FIGS.16A and B;

FIG. 17A illustrates the relationship between the personal page, theuser, the Internet, and the telephone company;

FIG. 17B illustrates the sequence of steps involved in creating andinstalling a service logic program (sip);

FIG. 18 illustrates an appliance interfaced to the personal page;

FIG. 19 illustrates matching a B.R. and vendor script that includeconditions;

FIG. 20 illustrates computer processes that are concurrently executed tomatch B.R.'s and vendor scripts;

FIG. 21 illustrates processing purchasing requirements in accordancewith user input;

FIG. 22 illustrates matching B.R.'s and vendor scripts when a B.R. isreceived;

FIG. 23 illustrates matching B.R.'s and vendor scripts when a vendorscript is received;

FIG. 24 illustrates a method for managing the B.R. activation list.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A personal page can be hosted by an Internet server. It may also behosted by the user's local computer, and, in some embodiments, can bemade visible to the Internet similar to the way napster.com makes filesresiding on a user's local hard drive accessible to other users of theInternet. In yet other embodiments, it may be hosted by a computer orcomputers that are electronically positioned in the network between theuser's local computer and an Internet server. In other embodiments, thepersonal page can be hosted on a computer or computers other than theuser's local computer and mirrored on his/her local computer, i.e., thetwo copies are synchronized and kept current with each other. In otherembodiments, the user's local computer hosts the personal page andanother computer(s) contains a mirrored copy.

FIG. 1A illustrates the overall architecture of one preferredembodiment. In this preferred embodiment the personal pages, e.g. 1, arehosted on one or more Internet servers, e.g., 2. There are also,preferably, one or more sites that contain the network addresses ofsites hosting personal pages. See 3. Based on this information, vendorscripts and B.R.'s are brought together to determine compatibility. Thedetermination of compatibility can be done at the site hosting thepersonal page, at the vendor's site, or at another computer accessibleto both. As noted, personal pages may also be hosted at users' localcomputers. The address information of such computers is also stored incentral location(s) accessible over the Internet. (See, e.g., 3. Severallevels of addressing also can be employed). A local user computerhosting a personal page is illustrated as 4. A local computer can be aPC, another Internet appliance, or a larger machine.

In a preferred embodiment, a personal page is comprised of computermemory, which, for example, stores B.R.'s. In this embodiment, apersonal page has associated with it software as described below. Thiscan include databases, executable code, libraries, applicationprocesses, and other such software known in the art for realizingInternet applications.

FIG. 1B illustrates the overall preferred organization where thepersonal pages (“pp”) hosting B.R.'s are stationary and the vendorscripts illustrated as “s” are mobile components. Preferably, therequirements (B.R.'s) and vendor scripts are created by users usingfixed length electronic input forms, preferably in the form of Webpages, presented to the user at his/her local computer as is known inthe art. The user completes the form and, when complete, clicks abutton, preferably called “enter” or “send.” The system then processesthe form, extracting the information in the fields, and stores the B.R.or vendor script thus created. Preferably B.R.'s are stored inconnection with a personal page. See FIG. 2. (In other embodiments, theB.R.'s and/or vendor scripts can be entered using variable length forms.In other embodiments, the B.R.'s and/or vendor scripts are stored by thesystem in their raw form, without conversion to another internal form.)Preferably, the processed information, extracted from the forms enteredfor B.R.'s and vendor scripts, are stored in data structures, akin to C“struct's” or Pascal “records,” called “purchase forms” and “vendorforms,” respectively. (As noted, these are not limited to sale of itemsand may relate to other information.) The B.R.'s and vendor scripts canalso be created using voice input whereby the user is prompted forinformation that he/she speaks into a microphone connected to the localcomputer or into a telephone, as is known in the art. Using voicerecognition techniques known in the art, the information is gathered andstored in a purchase form (or vendor form in the case of a vendor).User-dependent voice recognition software may be associated with apersonal page.

FIG. 3 illustrates the steps associated with voice input of B.R.'s(vendor scripts). Graphical techniques known in the art, including butnot limited to GUI, can be used to gather the information from the userwishing to input a B.R. or vendor script. Some of the graphicaltechniques that can be used include the user picking icons from a menuor list, which are then pieced together to compose the data constitutinga B.R. or vendor script. In general, various techniques known in the artfor obtaining information from a user can be used.

The Web page form presented to the user for the purpose of creating aB.R. (and similarly vendor script) is preferably a fixed lengthelectronic form, as mentioned above, with fixed, labeled attributes.(Attributes are fields, like the “attribute” notion in the RelationalData Base Model.) Attributes are assigned values input by the user, orNULL, which may appear as a blank to the user if he/she does not enter avalue. Optionally, some of the attributes may have values assigned tothem by the user clicking a button near the field, with the user thenchoosing from among a list of possible allowed values. Also, certaininformation not entered by the user may be assigned default values. Suchtechniques are know in the art.

In what follows, the purchase forms and their processing are described,with vendor forms handled in a similar way. The user is required toprovide values for certain attributes, such as “Action,” and techniquesfor enforcing that he/she do so are well known in the art. Action (e.g.,“purchase”, “sell,” “trade,” “license,” “reserve,” “rent,” “lease,”etc.), Item Name, Item code, UPC code, Date (of delivery), Place,Supplier, Quantity, Quality, Size, and Price are examples of attributesin a purchase form, but in alternate embodiments purchase forms cancontain other attributes as well and may omit some or all that are shownhere. Some attributes may be automatically assigned a default value. Insome embodiments, some or all of these attributes can have optionalqualifiers such as “maximum” (<=), “minimum” (>=), “earliest” (>=),“latest” (<=), etc., for example, specified with them. Examples include:

Action: purchase Item: airline ticket Place: Hawaii Date ofDelivery: >=Jan. 1, 2001 Action: reserve Item: hotel room Place: HawaiiPrice: <=$350/night Action: purchase Item: champagne Place: HawaiiPrice: >=$40In other embodiments, higher-level qualifiers such as, for example, the“between” comparison operator found in the SQL data base query languagecan also be supported. Each attribute has associated with it a “domain,”which, like its identically named counterpart in the Relational DataBase Model, is the set of all possible values that the attribute mayattain. A user may also specify how vendors should bid for items in aB.R. on a personal page, for example, at what time/date the deal shouldbe completed, whether the criteria for acceptance is the lowest price,and the like.

The processing of the Web page input form completed by the user tocreate the purchase form (vendor form) involves the following. Thesystem extracts the data from each attribute, checks that the value isin the domain of that attribute, and if so, stores the value in acorresponding field, with possible conversion, in the purchase form(vendor form). Illegal values cause the user to be sent the input formonce again with a message indicating that an attribute value (or values)lie outside the defined domain(s). Once processing is complete, thepurchase form (vendor form) is stored as the system's internal datastructure used to represent the B.R. (vendor script). See FIG. 4.Preferably, purchase forms and vendor forms are the same length and havecorresponding attributes. In other embodiments, they may have differinglengths and/or differing attributes.

A purchase form is “satisfied” against a vendor form if all itsattribute values are compatible with associated attribute values in thevendor form. In the preferred embodiment, compatibility of attributes isaided by a compatibility dictionary maintained by the system. Thecompatibility dictionary is preferably a database and associated programlogic that indicates whether two or more values in certain attributesare deemed compatible. For example, if the value for the Actionattribute in a purchase form is “purchase” and the value for the Actionattribute in a vendor form is “sell,” then the dictionary would indicatethat these actions are compatible. Action values “buy” and “sell” wouldsimilarly be deemed compatible values for Action in the dictionary. But“trade” and “license” would not be deemed compatible Actions, nor would“buy” and “buy.” Similarly, the values “100” and “<1000” would be deemedcompatible in all attributes, since 100 is less than 1000 universally,and “anytime next week” and “next Wednesday” would also be deemedcompatible universally. But “100” and “<50” would be deemed incompatibleas would “anytime next week” and “in 6 weeks.” Geographical attributevalues “outside New York Metropolitan area” and “Boston” would be deemedcompatible, while “New York Metropolitan area” and “Taiwan” would beconsidered incompatible. Preferably, the value NULL is compatible withall values, except the special value NOT NULL. Techniques for dealingwith NULL values are known in the art and can be found in Data BaseManagement Systems (DBMS's) that support the SQL Relational Data Basequery language, for example. In other embodiments, instead of, or inaddition to, NULL, there may be a special value DON'T_CARE thatindicates that any value is acceptable to the user in that attribute. Inother embodiments there may be a value PROMPT that causes the promptingof the user for a value at the time the system is attempting to satisfythe purchase form against the vendor form. In some embodiments, thevalue indicated may be a location on the user's computer (e.g., harddrive) or a location on a Web page at an Internet site at which thevalue is to be obtained by the system automatically. In general, varioustechniques known in the art for obtaining a value can be used. Otherembodiments may have other special values as dictated by the needs ofthe users. In some embodiments, the user may be given the ability todefine his/her own special values with their own special meaning, thusproviding an element of programmability to the user.

The compatibility dictionary technique can be used as an intelligenthigh-level macro feature allowing users to indicate a set or sequence ofitems and/or actions shorthand. For example, the user may create a B.R.that reads in part

Action: purchase Item: romantic vacation Place: HawaiiThe compatibility dictionary, containing a macro-like definition of“romantic vacation,” expands romantic vacation into, for example, theset “first class airline tickets, five-star hotel, flowers>$30,champagne, . . . .” Thus, the single purchase form above would generatea set of associated purchase forms

Action: purchase Item: airline ticket Place: Hawaii Quality: first classAction: reserve Item: hotel room Place: Hawaii Quality: five-starAction: purchase Item: flowers Place: Hawaii Price: >$30 Action:purchase Item: champagne Place: Hawaii Price: DON'T_CAREIn some embodiments, the user may be given the ability to define his/herown special definitions of terms, which can override and/or extenddefinitions contained in the dictionary. Preferably, the user can querythe dictionary for definitions contained within it. In some embodiments,the dictionary's contents can evolve automatically using techniques ofArtificial Intelligence. For example, software that scans newspaperadvertisements for vacations may automatically deduce the currentlyaccepted understanding of “romantic vacation” and enter or modify thedictionary entry appropriately.

In some embodiments, the user may be given the means of controlling thecompatibility dictionary used by the system in satisfying purchase formsagainst vendor forms. For example, the user may indicate to the systemwhich compatibility dictionary to use if more than one is available.He/she may even have the ability to edit the dictionary, or create acustomized personal one. There may be separate compatibilitydictionaries for each language: one for English, another for Spanish, athird for Russian, etc. Using techniques of Artificial Intelligence, thesystem may evolve a compatibility dictionary that is the result of“learning” what a user (or users in general, or a class of users)consider compatible and incompatible. Compatibility dictionaries may besupported that are particular to one industry or one class ofindustries, or to a class of individuals. Using techniques of ArtificialIntelligence, the user may be given the choice of “teaching” the systemwhich values he/she considers compatible and incompatible. A group ofusers may collectively agree to use a particular dictionary ordictionaries in some embodiments, or they may agree to refrain fromusing a particular dictionary or dictionaries. In some embodiments, aB.R. and/or a vendor script may have associated with it, as indicated bythe user, a designation of which compatibility dictionary ordictionaries are to be used and which ones are excluded from use in thatparticular instance.

In some embodiments, the user's B.R. (vendor script) Web page input formdescribed above may contain optional attributes that allow the user toindicate Boolean conditions. This is similar to the advanced searchfeatures found on Internet search engine sites, e.g. hotbot.com, thatallow the user to specify conditions required of pages that are returnedby the search. For example, the form may contain a “condition” attributethat allows the user to specify a B.R. such as

Action: purchase Item: airline ticket Place: Hawaii Condition: airline ≠TWA.Specifying and processing general boolean conditions are well known inthe art and such known techniques may be used in various embodiments.The language for specifying conditions preferably includes the abilityto express full Boolean logical expressions, as is known in the art.Thus, connectives such as, for example, AND, OR, and NOT are preferablyavailable to the user, along with comparison operators, such as, forexample, =, ≠, <, <=, >, >=, AT, BETWEEN, BEFORE, AFTER, etc.Preferably, wild characters, such as * for example, which are known inthe art, are also included to allow the user the ability to compose moregeneral conditions. The ability to compose “regular expressions,” as isknown in the art and found in systems such as the UNIX Operating System,for example, is preferably also included. Some embodiments may notchoose to include regular expressions, however. Some embodiments mayoptionally include conditional AND (CAND) and/or conditional OR (COR)connectives, as is known in the art.

The purchase and vendor forms in an embodiment that includescondition(s) preferably have field(s) called “condition1,” “condition2,”etc., in which the specified condition(s) are stored. Satisfying apurchase form against a vendor form in such a case preferably involvesevaluating the boolean condition(s) using well-known techniques forboolean evaluation. Preferably, values for items such as “airline” shownin the B.R. above come from attribute values in the vendor form againstwhich it is being evaluated, in this case the value for attribute“Supplier.” FIG. 19 illustrates matching a B.R. and vendor script thatinclude conditions.

In other embodiments, users are given the option of composing B.R.'s andvendor scripts in a scripting language reminiscent of a general purposehigh-level programming language. This may be in addition to, or in placeof, the electronic form technique discussed above, and may be combinedwith it. FIGS. 5 and 6 illustrate how B.R.'s and vendor scripts,respectively, specified in a scripting language are handled.

Discussed here is the technique for specifying B.R.'s, with vendorscripts being specified and defined in an analogous way. The userwishing to specify a B.R. expresses it in an IF-THEN-ELSE controlstructure, exemplified by the following extended BNF (Backus-Naur Form)grammar fragment, with (preferably reserved) language keywords appearingin bold:

-   <B.R.>:: <action><qualifiers>|<if>-   <if>:: IF <condition> THEN <B.R.>|IF <condition> THEN <B.R.> ELSE    <B.R.>-   <qualifiers>:: <attribute>:<value>|{<attribute>:<value>}-   <condition>:: well-known extended BNF describing boolean conditions    in attributes and constants as found in languages such as SQL's    “WHERE” clause, for example.-   <action>:: purchase|sell|trade|license|reserve|rent|lease| . . .    etc.-   <attribute>:: Item|Place|Price|Quality| . . . etc.-   <value>:: all nonempty strings of characters    Though not shown here, bracketing pairs of symbols such as C's { . .    . } or Pascal's BEGIN . . . END are preferably included in the    language to allow the user to associate an ELSE with an IF other    than the one closest to it. Techniques for disambiguating values    from attributes are well-known in the art and found in such    languages as SQL, for example. Grammar and language definitions    other than the one above can be used in alternative embodiments.

An example of such a B.R. might appear as

IF price < $1500 THEN purchase Item: round trip flight NYC-HawaiiQuantity: 2 Date: >= 1/1/2001 ELSE IF airline ≠ TWA AND price < $2000THEN purchase Item: round trip flight NYC-Hawaii Quantity: 2 Date: >=1/1/2001 ELSE purchase Item: round trip flight NYC-Hawaii Quantity: 1Date: >= 2/15/2001

Since a B.R. and a vendor script might mutually depend on one anotherand since satisfying a B.R. against a vendor script may be possible inmore than one way, IF-THEN-ELSE B.R. and vendor scripts are preferablyevaluated against each other to determine satisfiability as follows. TheB.R. is parsed using known parsing techniques in the field of compilerconstruction and based on an appropriately defined grammar. During theparse, each portion of the expression corresponding in the parse to thenonterminal <B.R.> is converted using the technique shown above to aseparate purchase form, since the data contained there is much like whatthe user would enter in an input form described above. A vendor scriptis handled analogously, resulting in a similar collection of vendorforms. The purchase forms (vendor forms) are ordered according to theiroccurrence in the B.R. script, from top to bottom. This can be done, forexample, at parsing time using an appropriately defined grammar andparsing technique. Preferably during the parse, each purchase form(vendor form) has associated with it a boolean condition that is theconjunction of all the IF conditions encountered on the path from thebeginning of the B.R. (vendor script) to that purchase form (vendorform), with the proviso that ELSE results instead in the logicalcomplement of its associated IF being used. Thus, in the previousexample, associated with the three purchase forms in the orderencountered in the parse are the conditions

-   -   price<$1500    -   NOT (price<$1500) AND airline≠TWA AND price<$2000, and    -   NOT (price<$1500) AND NOT (airline≠TWA AND price<$2000).        The collection of purchase forms and vendor forms with their        associated conditions are now evaluated pairwise against each        other using the technique described above for a single pair of        forms. In addition to all form fields being compatible, however,        the two associated boolean conditions must both evaluate to        true. (Values for attributes mentioned in the condition        associated with a form are taken from the form provided by the        other party.) Preferably, the order of evaluation is done in a        way that respects the order of the forms as encountered in the        purchase form sequence and vendor form sequence. Thus, for        purchase forms and vendor forms    -   p₀, p₂, . . . , p_(n-1) and v₀, v₂, . . . , v_(m-1)        respectively, the order of consideration follows the order        specified by execution of the C statement

for (i = 0; i < n; i++) for (j = 0;j < m;j++) evaluate p_(i) againstv_(j;)The first pair of forms that result in a satisfied B.R. successfullyends the evaluation, and the successfully matched pair are saved so thatthe deal between the user and vendor can be closed. If consideration ofall pairs fails, then the overall evaluation fails and no deal ispossible at this time. The implementation just described is biasedtowards the B.R. at the expense of the vendor script since the slowervarying outer loop indexes through the p's while the faster varyinginner loop indexes through the v's. In an alternative embodiment, theorder of the loops can be reversed. In other embodiments, the order canbe specified by the users and/or vendors. In other embodiments, theevaluation can be done in another order, even in a random order. In someembodiments, the order of evaluation can be nondeterministic.

FIG. 7 describes software executing on a computer that determinescompatibility between a vendor script and a B.R. As noted, thiscomputer, depending on the particular implementation, can be a computerhosting a personal page, a vendor site computer, or another computeraccessible to both. The system process in FIG. 7 awaits arrival ofvendor forms from a vendor. Once received, the process considers allpurchase form sets against the newly arrived vendor forms. The vendorforms are checked against each purchase form set for compatibility. Avendor and a user whose forms have been matched are notified as shown onFIG. 7. FIG. 8 shows how vendor and purchase forms are tested forsatisfiability. First, the associated booleans are evaluated. If theyboth evaluate to true, then attributes on the forms are checked againsteach other for compatibility using a compatibility dictionary. (See FIG.9.) If all attribute values are compatible, then the forms are deemedcompatible, otherwise incompatible.

FIG. 10 illustrates software supporting bidding in connection with auser who wishes to find the lowest priced item within a given timeperiod. After a user indicates a maximum acceptable price, which issaved by the system, a timer is set for a desired waiting time duringwhich bids are accepted. The executing process blocks until an eventoccurs, which is either expiration of the timer or arrival of vendorforms. On timer expiration, the vendor of the lowest compatible bid isnotified of acceptance. On arrival of vendor forms, an attempt is madeto satisfy the purchase and vendor forms. If not satisfied, the softwareblocks again. If satisfied, the vendor's bid is compared with thecurrently stored maximum acceptable price. If less, then the identity ofthe vendor and its bid are saved. The software then blocks until thenext event occurs.

Another embodiment adds a production of the form

<B.R.>:: <B.R.>,<B.R.>

to the grammar shown above, allowing B.R.'s (and/or vendor scripts) ofthe form

-   -   IF condition THEN p₁, p₂ ELSE p₃, p₄, p₅        for example, where the p_(i)'s are B.R.'s (vendor scripts). This        allows the user (vendor) to specify several purchases (sales),        for example, in a single B.R. (vendor script). The semantics        associated with p₁, p₂, . . . , p_(n) are that all p_(i) must be        satisfied. Preferably, their order is immaterial, but in some        embodiments the order may be relevant. Preferably p₁, p₂, . . .        , p_(m) is satisfied against v₁, v₂, . . . , v_(n) if for each        p_(a) there is a v_(b) and for each v_(c) there is a p_(d) such        that the pair p_(a)-v_(b) and the pair v_(c)-p_(d) are each        satisfied as described above.

Another embodiment of the matching process is described as follows. AB.R., in whatever form it is input, is first translated (compiled) intoa lower language equivalent using language compilation and translationtechniques known in the art. (This is described in more detail below.)The lower level language statement into which a B.R. is translated isreferred to as “alternative purchase statement,” whose syntax andsemantics are similar but not identical to the generalized if-statementcalled an “alternative command” known in the computer programming artand described in detail in the textbook The Science of Programming, byDavid Gries, SpringerVerlag, New York, 1981, pp. 131-137 (incorporatedherein by reference). Other symbols or codes can be substituted for theones shown here by an ordinary person skilled in the art.

Just as an alternative command is composed of “guarded commands” (seepage 131 in Gries), an alternative purchase statement is composed of“guarded purchase statements,” each of the form

-   -   guard→purchase-set        where “guard” is a boolean condition (or TRUE in the case that        no guard is necessary) and “purchase-set” is a set    -   p₁, p₂, . . . , p_(m)        Each p_(i) is preferably a purchase form, as described above        and, preferably, in most instances, the purchase-set has one        element, i.e., m=1. In other embodiments, m>1 and/or each p_(i)        is either an alternative purchase statement itself or a purchase        form. (This technique of defining a language structure        recursively in terms of itself is known in the art.) In other        embodiments, the p_(i) can encompass other things as well, such        as assignment statements, function calls, and other general        purpose programming language features. In other embodiments        “guard→” may be omitted in the case that the guard is TRUE,        namely “TRUE→purchase-set” can be shortened to “purchase-set.”

The guard acts as a logical guard at the gate→, making sure thatsatisfaction of the associated purchase set is attempted only under thedesired conditions, namely that the associated guard is true.Preferably, order of the p_(i)'s is irrelevant. In other embodiments,the purchase set may be contained within delimiters, and written {p₁,p₂, . . . , p_(m)} for example. Other syntactic forms that indicate aset of items are also possible and known in the art. In some embodimentsthe order of the p_(i)'s may be significant.

Unlike the alternative command where execution is insensitive to theorder of its constituent guarded commands because execution isnondeterministic (see page 111 in Gries), the order of the constituentguarded purchase statements in an alternative purchase statement isrelevant to the matching process since the matching process ispreferably deterministic. In some embodiments, however, the matchingprocess may be nondeterministic. If the B.R. composition language isvery high level and contains a nondeterministic OR connective, forexample, then it is preferable that the matching process benondeterministic as well. Some embodiments may include two types ofalternative purchase statements: one in which the matching process isdeterministic and another in which the matching process isnondeterministic. The description that follows describes thedeterministic alternative purchase statement. Those skilled in the artcan adapt and extend what is described here to the nondeterministiccase.

An alternative purchase statement preferably takes the followingsyntactic form

[guard₁→purchase-set₁□guard₂→purchase-set₂□ . . .□guard_(n)→purchase-set_(n)]where the □'s serve to syntactically separate the constituent guardedpurchase statements. In other embodiments, the syntax may differ.Evaluating an alternative purchase statement is described further below.

For illustrative purposes, consider the IF-THEN-ELSE B.R. script shownabove. It would be translated preferably into an alternative purchasestatement such as

[ price < $1500 → p₁ □ price >= $1500 AND airline ≠ TWA AND price <$2000 → p₂ □ price >= $1500 AND (airline = TWA OR price >= $2000) → p₃ ]where p₁, p₂, and p₃ stand for the three purchase forms shown in theearlier example and are abbreviated here merely for convenience. Morecomplex B.R.'s would translate into correspondingly more complexalternative purchase statements.

Translating an IF-THEN-ELSE B.R. into an alternative purchase statementis done using compiler and programming language techniques as known inthe art. Preferably, the translation procedure is such that an IFkeyword in the B.R. results in a guard being generated, and a THEN orELSE (without an IF following it) in the B.R. results in a new purchaseform being generated.

In some embodiments, the user may be given the ability to composealternative purchasing statements him/herself directly, thus bypassingthe process of composing a B.R. that is then translated to a lower levellanguage equivalent. In other embodiments, the user may be given theability to compose purchase forms directly.

Preferably, vendor scripts are also translated into lower levelequivalents, similar to the way B.R.'s translate. In alternativeembodiments, however, only B.R.'s are translated while vendor scriptsare left untranslated. In other embodiments, only vendor scripts aretranslated while B.R.'s are left untranslated. In other embodiments,vendor scripts and B.R.'s translate into different lower level languageequivalents. It is also possible using natural language processingtechniques known in the art of Artificial Intelligence to do thematching of B.R.'s and vendor scripts in their raw, untranslated form.In other implementations, B.R.'s and/or vendor scripts can be translatedinto equivalents in languages that are lower level than the oneillustrated above.

Satisfying a user's B.R. is done preferably by evaluating thealternative purchase statement that it translates into against asimilarly translated vendor script. (For convenience, we will continueto refer to these translations as B.R.'s and vendor scripts,respectively. As noted above, a form is a lower representation than ascript. Also as noted above, a script is provided as a result of userinput and then it is translated into one or more forms.) We firstdescribe the technique of trying to satisfy a B.R. against the simplestof vendor scripts, namely, one that translates into the equivalent of asingle vendor form. The technique for dealing with more complex vendorscripts is described below. We will describe the technique for dealingwith a single vendor script. The method can be extended by one skilledin the art to the situation of several vendor scripts. The techniquepreferably proceeds as follows. A (deterministic) alternative purchasestatement is evaluated sequentially from top to bottom, i.e., from thefirst guarded purchase statement to the last. Evaluation terminatessuccessfully when a guarded purchase statement is satisfied, andunsuccessfully if all guarded purchase statements cannot be satisfied. Aguarded purchase statement is satisfied by a vendor script if its guardevaluates to true and all p_(i)'s in the associated purchase set can besatisfied against the vendor form. Evaluation of a guard may involve thequerying of a vendor's Internet site, similar to the way guards in theconcurrent programming language known as Communicating SequentialProcesses (CSP) can contain interprocess communication commands.Satisfying a purchase set might also involve accessing an Internet site.(This is analogous in CSP to the appearance of interprocesscommunication commands in the nonguard portion of a guarded command.)

We now describe the way of satisfying a B.R. against a more complexvendor script. (The technique can be extended to the case of severalvendor scripts.) In this case, the B.R. and vendor script eachtranslate, preferably, to alternative statements of the form

[u-guard₁→purchase-set₁□u-guard₂→purchase-set₂□ . . .□u-guard_(n)→purchase-set_(n)]and

[v-guard₁→vendor-set₁□v-guard₂→vendor-set₂□ . . .□v-guard_(m)→vendor-set_(m)]

respectively. The system then combines the two into a single alternativeuser-vendor statement

$\left\lbrack {\left. {{\underset{{i = 1},{j = 1}}{\overset{n,m}{\square}}u}\text{-}{{guard}_{i}\bigwedge v}\text{-}{guard}_{j}}\rightarrow{{purchase}\text{-}{set}_{i}} \right.;{{vendor}\text{-}{set}_{j}}} \right\rbrack$

where “

” is logical conjunction of the two guards. Preferably, the guardedstatements are combined so that smaller i,j values appear before largerones to respect the order of evaluation in the original guardedstatements. The alternative user-vendor statement is then evaluatedpreferably using the technique described above, with the added provisionthat “purchase-set; vendor-set” is satisfied if for each p_(a) inpurchase-set there is a v_(b) in vendor-set and for each v_(c) invendor-set there is a p_(d) in purchase-set such that the pairp_(a)-v_(b) and the pair v_(c)-p_(d) are each satisfied as describedabove.

After a user's B.R. has been found to be satisfied by a vendor script,the processing moves to the next stage of deal closure. When a match hasbeen identified as discussed herein, the deal can be closed in one ofthree ways: (1) it can close automatically; (2) it can be closed onlyafter user confirmation; or (3) after additional verification by allparties regarding the terms of the deal. For example, the first casepertains to the purchase of simple consumer goods, e.g., groceries orstaple articles of commerce. The second case may be used for morecomplex purchases, e.g., airline tickets. The user confirmation in thiscase can be provided by an electronic message from the user in textualor voice form (subsequently converted to data) or another form known inthe art. The third one is typically used for transactions that aresufficiently complex that they require a formal agreement.

FIG. 11 illustrates the preferred processing for the third case, wherethe system processes the closing of a deal between a buyer and sellerwho require verification of agreement. Although shown here is a singlebuyer and a single seller effecting a transaction (i.e., a two-waydeal), those skilled in the art can readily extend the technique shownto a multi-way transaction (multi-way deal) involving several sellersand/or several buyers. At 50, one of the parties to the deal, theseller, for example, requests a deal identifier (ID) from a serversupervising the closing of the deal, e.g., the server hosting thepersonal page. The deal ID is a unique identification of the particulardeal, allowing distinguishing from other deals. Techniques forgenerating unique ID's are well known in the art, and can be done, forexample, by storing an integer at the server that is incremented eachtime a deal ID is requested, this incremented value becoming the latestdeal's ID. Other techniques are known in the art for generating uniqueID's in distributed environments where there is no single centralcomputing facility such as a server. When the party requesting the dealID transmits such request to the server, the server generates the ID andtransmits it back to the requesting party's client computer. (See 51.)Alternatively, a party may have requested a number of deal ID's from theserver previously and stored them in the local memory of his/her clientcomputer. Then, to close a given deal, the party selects one of theseunused deal ID's. As shown at 52, the user then sends the deal ID to theother party by email or by Instant Message (IM) or by voice telephone orin person or by postal mail or by any other method or means he/she deemsappropriate. Alternatively, the server can forward the same deal ID toboth parties simultaneously eliminating the need for one party to sendit to the other. Once both parties have received the same deal ID, oneor both parties request that the server transmit forms to both partiesfor a particular type of deal. Types of deals may include, for example,sales, swaps, licenses, etc. The form may include a description of theproperty or properties involved in the transaction, identification ofthe parties involved, selling price if applicable, license fees ifapplicable, date of effect, other terms and conditions, etc. Inresponse, the server transmits the deal forms to both parties of thedeal. Thereafter, both parties independently fill out the terms of thedeal using the form received from the server. In some embodiments bothparties may attach a digital signature to the form Then, both partiessend their respective forms to the server, though not necessarilysimultaneously. (See 60 and 61.)

The server receives the electronic forms from the parties and storesthis information in the database as a deal-in-process. Once the serverhas stored the forms from both parties as a deal-in-process, it comparesthe fields in the records identified by the same deal ID's. (See 65). Ifthe fields in the records are compatible, the server marks the deal asclosed. In the preferred embodiment, compatibility is defined by thefields being identical, but in other embodiments compatibility can bedefined by looser criteria, such as, for example, selling price andbuying price differing by less than a designated percentage, the term“12 months” being considered equivalent to the term “1 year,” the “term30 days” being equivalent to “1 month,” etc. Such techniques fordefining compatibility and implementing software accordingly are knownto those skilled in the art. Alternatively, the compatibility dictionarytechnique described above can be used here as well. Once the deal isclosed, the server sends confirmation messages, by email, for example,to both the buyer and the seller. It may also generate an electronicand/or non-electronic agreement and attach the electronic and/ornon-electronic signatures provided with the forms when such signatureshave been supplied. (See 78). If at 65 the terms did not match, thesystem sends a message to both the buyer and the seller indicating thediscrepancy. (See 80.) Alternatively, only one of the parties isnotified that there is a discrepancy. (It may be the party initiatingthe transaction, or it may be the seller, for example.)

In one embodiment, the user (or vendor) can also indicate requirementsat a higher syntactic and semantic level, from which the system willtranslate to lower level equivalents using techniques found in the art.Thus, the user can specify, “I wish to get a haircut LIKE my haircutlast month,” and the system will retrieve the prior month haircutpurchase and use it to compose the currents purchasing requirement.(Keywords such as LIKE shown here may be introduced into therequirements composition language to provide additional expressiveness.)A full macro capability may also be made available to the user, as wellas language learning techniques adopted from the area of ArtificialIntelligence so that the system may over time and possibly with training“learn” the semantics associated with the personal language style of theuser. Automatic voice recognition techniques, as known in the art, mayalso be used to compose the B.R. data directly from user voice input.Graphical specification methods and devices as are known in the art mayalso be used, including but not limited to GUI techniques.

Various capabilities associated with general purpose proceduralprogramming languages, such as, for example, variables, branching logic,and repetitive constructs, may be employed for constructing B.R.'s andvendor scripts. Functions found in general programming languageenvironments may also available, such as MAXIMUM and MINIMUM, forexample. Special keywords, preferably, may also included, such as LOWESTPRICE, MINIMUM DISCOUNT, SUPPLIER OF, and GRADE, for example. Further,features of nonprocedural programming languages, such as are found inPROLOG or parts of SQL (ANY, ALL, and SOME, for example), may also beincluded in the B.R.'s and vendor scripts.

Libraries of B.R.'s and vendor scripts can be made available to the userto aid in composition. Using the history of previous purchases made by aparticular user, the system may be able to detect patterns of purchase,which the system can then use to automatically compose or translatepurchasing requirements and bidding rules for him/her.

The system as a whole may also build a database of B.R.'s generated bythe users of the system over time and evolve an understanding ofpatterns of language use that will enable more automatic translation ofhigh level requirements into lower level equivalents. The user can alsoindicate default requirements that ought to apply in the absence of onesspecified for a particular purchase. In addition, the user can designatecertain bidding rules and purchasing requirements that must apply to allor some purchases even when not explicitly included for a particularpurchase. (For example, the user may indicate that “All products mustadhere to Milspec standards,” or “All software must be Y2K compliant,”or “All meat must meet USDA Grade A standards,” or “All products must bemanufactured in the United States,” or “All consumer products evaluatedby Consumer Reports must be rated ‘A Best Buy’.”) In some embodiments,the user can reference other users' purchasing requirements and biddingrules, and may even extend them. (“Use John Smith's bidding rules andrequirements for all products except software.”) Users can make some orall of their rules and requirements available to others, and thelanguage for controlling visibility and adoption and extension of one'sbidding rules or purchasing requirements by others can be similar to theway visibility and sharing is controlled in other areas of computing,for example, PRIVATE and PUBLIC scoping rules and CLASS extension inObject Oriented Programming languages.

Purchasing requirements can have conditional temporal components aswell. (“In winter all oranges must originate from Florida and in summerall oranges must originate from South America,” or “Purchase 1000bushels of wheat before December 15.”). Various trading rules andstrategies may also be associated with the personal page, and thelanguage for expressing them is, preferably, similar to the languageused to express purchasing requirements as discussed above.

Items that can be purchased through the personal page can be selectedfrom a searchable database of all available items. Preferably, a largefraction of items available commercially are included in the database.In the case that such a database is used, the user causes invocation ofa conventional database search, locates the desired item that conformsto the user's requirements, selects it, and specifies deliveryrequirements. In some cases, the user can select a generic item, e.g., acomputer with certain memory and storage characteristics, withoutspecifying the brand. (The language may include a BRAND keyword tofacilitate this.)

As noted, since the personal page is associated with a specific user(and perhaps his/her designees), it can include voice data for speakerdependent voice recognition, as described above, which can provide highquality recognition. Upon recognition of the voice command specifyingthe order, a confirmation can be displayed to the user. In addition, theuser can provide such a voice order from his/her Internet enabledcellular phone, or even from a conventional noncellular phone. The usertouches a button that automatically connects to his personal page andthen speaks the order on the telephone. The order is voice-recognizedand parsed. Optionally, then, the user is provided with a confirmationof the order that is read back to him/her on the phone. Varioussequences of steps can be employed for providing voice input to apersonal page. One example of voice input is shown in FIG. 3.

Sites that host the personal pages of multiple users can provide theability for collective bidding. That is, software at these sites mayscan personal pages and identify common desired items and constraintsassociated with them. Then, common items with similar constraints can bepooled so that users are well positioned for volume purchasing. Theseaggregated items can be pooled to separate super-personal-pages(“virtual personal pages”) which are also visited by vendors' electronicrepresentatives. In yet another embodiment, software agents can “roam”users' personal pages on the network and organize buying pools bygenerating virtual personal pages.

Such an arrangement, where each user conducts electronic commerce usinga personal page, provides enhanced privacy to the user. The user canspecify whether he/she wants none, or some, or all the marketinginformation contained on his/her personal page to be visible to othersand perhaps pooled and, if so, on what conditions. From the vendor side,marketing organizations have a very valuable commodity when they gathermarketing data made visible by a user from his/her personal page, sinceall of a user's market activities are captured centrally on that page.

The user may also control advertisement using the personal pagetechnique. A user could actively invite selective advertisements, whichwould then be provided to the user by vendors' electronicrepresentatives. This feature could be implemented by the marketplace(described below in an alternative embodiment), where users' invitationsfor advertisements are matched with vendor electronic representatives.Alternatively, the system could allow electronic advertisementrepresentatives, similar to vendor electronic representatives describedabove, to be sent to personal pages, which are then matched with users'invitations for advertisement. See FIG. 12. Preferably, personal pagesare not financed by advertisement, but instead by small transaction feescharged by the marketplace or by the vendors or vendor associations.

As noted, desired items on personal pages are not limited to specificgoods but may also include services. Such requests for services mayspecify additional relevant parameters, such as a requested time for theservice to be provided. In the preferred embodiment, the electronicrepresentatives of service providers attempt to accommodate such servicerequests. Upon a match on price, time, location, etc., the service isscheduled accordingly and the user is notified. Service requests can bevery general, such as “Provide a man's haircut<$45 in midtown Manhattanafter 5 μm any day next week.” Similarly, vendors' electronicrepresentatives can have calendar features, such as “Fill 4 μm slot forman's haircut costing>$30 on West 45 Street in Manhattan at 6 μm nextTuesday.” In the preferred embodiment, the marketplace will matchservice requests with vendor representatives in an optimized fashionusing scheduling optimization techniques as is known in the art, thuscreating a more efficient service economy.

Items can be delivered to the user physically, e.g., by a carrier to hishome, or they may be delivered electronically, i.e., by downloading them(e.g., music and books) to the user's local computer. Physical deliverycan also be provided from a center where a user would be able to reviewand exchange items.

A personal page may include banking information for making payments(e.g., credit card data) and obtaining banking services. Since thepersonal page may be where a user conducts business, adequate security,preferably, would be provided to assure protection. This information canbe easily retrieved by a user with a cell phone or hand held mobileInternet appliance. Also, highly personal data, such as medicineprescriptions that must be periodically renewed, can be located on one'spersonal page.

Vendors may post information about items they offer on their Web sites.Preferably, then, the system would gather this published data andcombine it into a list of available items. Thus, the system periodicallyupdates the database of available items by visiting Web sites ofvendors. Alternatively, vendors may submit information about the itemsthey offer for inclusion in the system database.

Purchase strategies can be expressed in the B.R. (vendor script) at ahigh level. For illustrative purposes, consider the following simplehigh-level B.R.:

-   -   PURCHASE m tons of wheat from SUPPLIER A if it can deliver m        tons, BUT IF it cannot THEN IF price from SUPPLIER B<$x THEN        PURCHASE n tons ELSE PURCHASE p tons from SUPPLIER C.        It would be translated preferably into an alternative purchase        statement such as

[ supplier A can deliver m ton of wheat → purchase m ton of wheat fromsupplier A □ supplier B sells wheat < $x/ton → purchase n ton of wheatfrom supplier B □ TRUE → purchase p ton of wheat from supplier C ]The three purchase sets shown here are actually simple purchase forms asdescribed above. More complex B.R.'s would translate intocorrespondingly more complex alternative purchase statements.

In some embodiments, the system can maintain a library of the mostcommon high level B.R.'s (vendor scripts), which have beenpre-translated—manually if necessary—into equivalents in lower levelIF-THEN-ELSE scripts or alternative statements. These high level B.R.'s(vendor scripts) can be quite complex, and are preferably parametricallydefined, with values for the parameters supplied by the user at the timeof use. The user then chooses an appropriate B.R. (vendor script) fromthe library and supplies parameter values such as price, delivery date,etc. The user may even be given the ability to compose booleanconditions for particular parameter slots. The library can evolve overtime using Artificial Intelligence techniques to include ever higherlevel B.R.'s (vendor scripts). Libraries of B.R.'s (vendor scripts) canbe managed similar to the way compatibility dictionaries are managed asdescribed above.

In addition to the attributes discussed above, many others can be usedas well: credit rating, previous history, etc., for example. The B.R.(vendor script) language and its associated software can provide thecapability of creating purchasing strategies whose evaluation logic isdynamically based on the offers (requests) they receive, i.e.,dynamically determined at the time the B.R. is evaluated against thevendors' scripts. In addition, software may initiate searching databasesof suppliers with a presence on the Web (but not necessarily combined onthe same site) and retrieve all relevant data if the user has soindicated on his/her personal page.

Strategies can be defined that change dynamically based on externalcriteria. For example, if the purchaser is a manufacturer who buysvarious items required for its manufacturing process, its purchasingstrategy may be dynamically determined by the number of outstandingorders it currently has for its products, and may involve, for example,asking for a bulk discount because it is making larger purchases.Similarly, vendor scripts can have similar dynamic features.

Also, several users can develop common, joint purchasing strategies,joining together to purchase items they both need. If, for example, oneuser's business is slow and another one's is doing well, the allocationbetween them of their common purchases can change. The adjustment canalso be dynamic and automatic, based on the volume of orders appearingon their Internet sites, for example. Suppliers can also cooperate tomeet the requirements of these strategies, subject of course to therelevant anti-monopoly and trust laws and regulations.

The personal page is generally useful, with application beyond what hasbeen described thus far. It is preferably a programmable Web-page likeelectronic entity with partial or total visibility to other Internetparticipants. In the preferred embodiment, the user can access his/herpersonal page through means such as, for example, wireless handheldInternet devices, wireless networks, voice recognized input devices,cable, cellular telephones, etc., as well as traditional Internet accessdevices such as the Personal Computer communicating with an InternetService Provider (ISP) by telecommunications. In other embodiments, theuser carries an electronic device such as a wireless Internetcommunicator (or is in a vehicle so equipped) that is in electroniccontact with the Global Positioning System (GPS), and this electronicdevice is also in electronic communication with his/her personal page.Thus, the personal page software has access to the geographical locationof its owner, and the personal page software logic executes inaccordance with that current geographical location. For example, if sucha user has programmed the personal page to notify him/her should he bewithin five highway miles of the home of his aunt, who is ill, and theuser chances to enter the five mile distance, then the personal pagesoftware logic will notify him/her through his electronic communicatorthat he should visit his sick aunt. Similarly, for example, the user canprogram the personal page to be notified if he/she passes within twoblocks of a supermarket to buy a quart of milk. The personal page mayhave electronic access also to other user appliances, such as his/herautomobile, for example, and the user may be notified by personal pagesoftware logic that the fuel level is low and that he/she is now withinone mile of a gas station. Or, for example, if there is a mechanicalmalfunction in the automobile, the personal page software may notify theuser that he/she is within a certain mile distance of an authorizedrepair shop, and may even guide the user to that destination inaccordance with GPS. See FIGS. 13, 14A, and 14B.

The personal page, preferably, can be accessed by the user using voicerecognized input techniques as are know in the art. The user speaksinstructions into an electronic device connected to the personal page,which may be a suitably equipped cellular phone, for example, and issuesinstructions that cause the personal page to be appropriatelyprogrammed. Once programmed, the personal page can be visited by otherInternet participants who interact with it. So a user, for example,might speak the instruction “Make an appointment with a dermatologist”into a cellular telephone and voice recognition software will,preferably, translate and it into an appropriate construct that isstored on the user's personal page, which then can be visited bysoftware agents associated with dermatologists looking to fill theirappointment calendars. See, e.g., FIG. 3.

Similarly, user's personal data can be stored on the personal page aswell. Users' medicine and vision prescriptions and other medical historyor conditions and data; dental records; personal dining habits (whichrestaurants, which kinds of restaurants); clothing and shoe sizes;cultural and social preferences; schools attended; financial history andcredit data; domestic and foreign travels; criminal records; purchasesmade; photo and voice data; family data; etc., are all examples ofthings that can appear there. Personal historical data may also appear,such as service in the armed forces, jobs held, educational test scores,etc. Other embodiments may contain data and types of data not listedhere. Personal page software can then use the stored data in itsinteraction with the Internet and/or with the page's owner. For example,in an embodiment where the personal page interfaces to GPS, as describedabove, the personal page software may notify the user that he/she is nowthree blocks away from a pharmacy where he/she should refill a medicineprescription that is running low. Similarly, personal page software mayinform the user that he is two blocks from a shopping mall and next weekis his/her mother's birthday. See, e.g., FIGS. 13, 14A and 14B.

Other entities may also have access, albeit preferably in a limited way,to a user's personal page. A pharmacist filling a user's prescriptionmay enter that fact along with relevant data onto the user's personalpage. Similarly, all or some of a user's medical records could be storedon his/her personal page, thus providing easy and instant access tothose records by any doctor treating the user. In alternativeembodiments, all or part of the user's personal page could be stored ina nonvolatile, compact form, on a programmable mini-disk, for example,for immediate access. In some embodiments, special purpose electronicdevices for interacting with a user's personal page could be available.When applying for a loan, for example, the user could insert his/herpersonal page mini-disk into a special reader located on the bank'spremises, thus giving the loan officer instant access to the applicant'sfinancial data and/or history and/or criminal record. In otherembodiments, instead of presenting the bank with a mini-disk that isthen read at the bank, the user may allow the bank software access tohis/her personal page located on the Internet.

In some implementations, the user's personal page could be used as apassport when traveling, in lieu of the hard copy booklet now used forthat purpose. The user could present a mini-disk passport when enteringor leaving a country, which would be read and/or written onto by aspecial reader. In other embodiments, the user could make accessiblehis/her personal page located on the Internet to passport officials whenentering or leaving a country. Using encryption techniques known in theart, such data could be made secure.

The personal page could be used as personal identification by the userin some embodiments. If the personal page contains photo images of theuser, for example, then it could be used as a photo id. It could alsocontain user voice data, thus acting as a voice id as well. Lawenforcement agencies could use a convicted criminal's personal page tokeep track of the whereabouts and dealings of the user, for example, andgovernment agencies could use the personal page as an electronic“license”, say a drivers license or firearms license for instance. Inthat case, special readers, perhaps wireless and hand held, could beused by police officers in accessing the personal page. In otherembodiments, the personal page license may be accessed on a mini-diskcarried by the user.

In addition to the applications described thus far, the personal pagehas other uses as well. For example, it could be used by its owner tosubstantially optimize his/her purchases and acquisitions of goodsand/or services. The user indicates on the personal page, for example,that he/she wishes to buy gifts for three friends, and that the totaloutlay should not exceed a certain cost, say $400. He/she can alsoindicate preferred categories of gifts, such as golfing equipment forthe first friend, music CD's for the second friend, and books for thethird. The user may have the opportunity of providing even finerpurchasing requirements, such as indicating a category of CD's, sayclassical music, from which the purchase is to be made. Similarly,he/she can indicate that the cost of a particular gift is to be no lessthan a given amount, or between certain minimum and maximum amounts.Other possibilities that constrain the purchase as known in the art arealso possible.

Once the purchasing requirements have been input, personal pagesoftware, preferably interacting with various sites on the Internet,compute various substantially optimal purchasing strategies usingoptimization techniques as are known in the art. (In alternativeembodiments, interaction with the Internet may not be necessary. Thiswould occur, for example, if the personal page software has locallyavailable to it an appropriately extensive database of goods andservices available for purchase.) The substantially optimal purchasedecisions are presented to the user, who has the option of choosingamong them. The user can then choose, if so desired, to purchase one ormore of these items online, using purchase techniques as discussedabove, such as B.R.'s.

The process can iterate. The user, having been presented withsubstantially optimal purchase recommendations based on the specifiedconstraints, may choose to partially accept the system'srecommendations. Having done that, the user can, optionally, change someor all requirements and ask the system to recompute the substantiallyoptimal purchases for the remaining ones. Referring to the example citedabove of a user wishing to purchase gifts for three friends, he/she mayelect to accept the system's recommendation for gifts for one or twofriends, for example, and then, optionally, change some or allrequirements and ask the system to recompute optimal purchases for theremaining friend(s). See FIGS. 15A, 15B, 16A, 16B, and 16C. FIGS. 15Aand 15B describe interaction with the user. It should noted that thelist of feasible items is provided to the user. The user is alsoprovided with pull-down menus from which he/she can cycle through theavailable items and make selections if the system's choice is not tohis/her liking. FIGS. 16A and 16B show an example of how the systemdetermines a substantially optimal purchase for two slots (items). FIG.16C provide pseudocode of the two-slot example shown in FIGS. 16A and B.

Another application of the personal page involves programmablepersonalized telephone service. Preferably, this feature involvestelephone company (and/or cellular telephone company and/or cablecompany, but for simplicity referred to here as “telephone company”)interaction with the user's Internet personal page. (In otherembodiments, the telephone company does not electronically interact withthe user's page, but instead electronically accesses the user'stelephone or cellular phone.) This feature allows the user to customizehis phone service by programming telephone features on his/her personalpage. The customization can be changed by the user by simply calling upthe personal page and reprogramming or modifying the service logic.Programming, reprogramming, or modifying service logic is preferablydone by accessing the Internet personal page using interactive means,but can also be done using voice input and voice recognition techniquesas are known in the art. Preferably, the service logic is communicatedto the personal page using a high level scripting language that is asclose to natural language as possible, but lower-level interfaces, onesinvolving prompts and/or electronic forms that the user completes, arealso possible in addition to or in place of higher level ones. Graphicallanguages as are known in the art for specifying service logic are alsopossible. Graphical methods, including but not limited to GUItechniques, may also be used. In general, all means of interacting withthe personal page as known in the art can be used to program, reprogram,or modify the service logic contained there. A user can have manyservice logic scripts if he/she wishes, and they can be stored inservice script libraries. Techniques of Artificial Intelligence as knownin the art can be used to automatically construct service logic programsby monitoring the user as he/she interacts with the telephone over aperiod of time and “learning” the user's preferences. FIG. 17A shows therelationship between the personal page, the user, the Internet, and thetelephone company.

The user's service logic specifies how he/she wishes telephone serviceto be governed. The user may, for example, specify that between thehours of midnight and 8 am all incoming calls are to be routed toanother number, or certain incoming calls (based on the caller ID, forexample) are to be blocked, or that the user wishes a wake-up call in 2hours or at a certain hour. Similarly, the user can, for example,provide different outgoing messages based on the caller ID or class ofcaller ID's, or different outgoing messages for different time periods.For example, the user may have one message for all callers outside hislocal area, another one for specific caller ID's, another one for allcaller's calling from a specific area code, etc. Call waiting featurescan be customized, with the user specifying which callers (based oncaller ID, for example) he/she is willing to be interrupted for. Theuser can even elect to assign priorities to caller ID's, and specify inthe service logic how to handle the situation of receiving a call from acaller of priority i while talking to a caller of priority j. (Forexample, “IF j<i THEN allow interruption ELSE play outgoing message 3.”)The user may also, for example, choose to use different long distancecarriers during different time periods (weekday, night, weekend forexample) to take advantage of the best price available at the time acall is made. In this case, the user's local computer's memory and/orthe user's Internet browser and/or personal page may have access to longdistance carrier rates available on the Internet and can interface toservice logic programming tools so that the best strategy for decidingwhich carrier to use during a particular period can be at leastpartially automated by the software. Optimization techniques known inthe art for creating an optimal long distance carrier schedule (whichcarrier to use during which periods) can be used in constructing theservice logic. In general, all techniques known in the art forspecifying and generating telephone service can be used.

Whenever a user's service logic is programmed, reprogrammed, or modifiedon his/her personal page, the service logic is preferably downloaded tothe telephone company's computer. This is preferably done using Internetcommunication and Internet communication protocols between the twocomputers, but can be through direct connection or through wirelesstransmission instead. In general, any and all means known in the art forcommunicating between computers can be used. Preferably, the servicelogic is translated to a lower level language equivalent so that itsexecution is as efficient as possible. Once the service logic isresident in the telephone company's computer, the logic is invokedwhenever certain triggering events occur, such as, for example, thearrival of an incoming call, reaching a certain moment in time, goingoff-hook, going on-hook, etc. The user's service is handledappropriately in accordance with the dictates of the programmed servicelogic. FIG. 17B illustrates the sequence of steps involved in creatingand installing a service logic program (sip).

In an alternative embodiment, the service logic is resident in a device(or devices) at the user's location, such as the user's telephone set,telephone answering machine, computer (personal computer, for example),cellular phone, beeper, pager, television set, other hand heldappliance, etc. The service logic executes locally, in the device thatit is resident in, and is triggered by events such as, for example, thearrival of an incoming call, reaching a certain moment in time, etc.Examples shown above of the various ways service can be programmed bythe user apply here as well.

If the user's local computer (personal computer, for example) containsthe service logic handling the user's telephone service, then the user'sInternet browser and/or personal page can interface to the servicelogic. In this fashion, the service logic can be kept up-to-date toadjust to changing circumstances. For example, the user's Internetbrowser and/or personal page can periodically download the latest longdistance carrier rates and store them on the user's local computer sothat the service logic can make its decisions based on the most recentdata. In general, the service logic can use a locally stored database toaid it in its real-time execution decisions, and that database can bekept up-to-date automatically by the user's Internet browser and/orpersonal page. (For example, if personal page software detects over theInternet that one of the user's acquaintance's has just been elected tohigh office, then the software can upgrade the acquaintance's priority,as discussed above.) In some embodiments, the actual service logicitself can be modified by the Internet browser and/or personal page. Forexample, if the user is using a service logic program obtained from anoutside source, over the Internet say, and the personal page hasdetected that an upgrade to the service logic program is now available,the personal page software can download the upgrade and apply it to theservice logic program. Any and all techniques known in the art forautomated management of software upgrades, preferably over the Internet,can be used to maintain service logic programs.

The user can also, in some embodiments, use buying request scriptsdescribed above to locate new service logic programs. The user creates ascript such as, for example, the following on his personal page:

-   -   PURCHASE telephone service logic program WITH personalized        outgoing message feature AND priority user feature<$25.        Then when the buying request has found/purchased a new service        logic program using the technique described above, software can        automatically download it and install it on the user's computer.

This technique of creating a buying request script on the user'spersonal page, which then locates a service logic program, preferably onthe Internet, downloads it, and then installs it locally on the user'scomputer can be used to locate, download, and install other types ofsoftware and/or data as well, not only telephone service logic programs.For any appliance that contains software and/or data, such as, forexample, a telephone, television, video camera, CD player, calculator,clock, electronic organizer, camera, automobile or other vehicle,microwave oven, washing machine, stove, medical machine, dental machine,automobile diagnostic machine, factory machine, farm machine, militaryweapon or machine, telephone switching system, etc., and that isconnected to the user's computer (through wire or wireless means), abuying request script located preferably on the user's personal page canbe used to locate, download, and install software and/or data on thatappliance. In this case, the user's computer installs the downloadedsoftware and/or data on the appliance preferably through thecommunication medium (wire of wireless) linking it to the appliance. Theappliance need not be necessarily permanently connected to the user'scomputer to use the method just described. See FIG. 18.

In other embodiments the appliance can be connected to the Internetdirectly, preferably through its own computer. In some embodiments theappliance can have it's own personal page. Appliances that are connectedto the Internet, whether directly or through a user's computer, can beinteracted with and controlled from elsewhere on the Internet. Forexample, if the appliance is a video camera (or collection of videocameras) in a house that is connected to the Internet, then the homeowner on vacation, for example, in another location can connect to theInternet locally and access the camera's Internet page (preferably itspersonal page) and view real-time images of the interior of his house tosee that everything is in order. He/she can, in some embodiments,control the camera (s) and reposition it (them), thereby improving theview, zooming in on a particular portion of a room, for example. Thecamera(s) may be on the exterior of his house as well. Other appliances,such as a stove, microwave oven, water heater, furnace, office machine,factory machine, etc., can be similarly remotely controlled if connectedto the Internet. Thus, for example, a user on his/her way home from workcan connect to the Internet through a wireless communication device asis known in the art, visit the Web page associated with his/her coffeemachine at home, and issue a remote command that switches the machine onso that fresh coffee will be ready when he/she arrives home. The usercan, in some embodiments, reprogram the appliance remotely through theInternet linking him/her to the appliance. This is preferably done bythe user visiting his/her personal page, creating a purchase script(B.R.) as described above to locate an appropriate program for theappliance. Once found, the script downloads the appliance program to theappliance itself through the appliance's Internet connection (or throughthe user's computer to which the appliance is connected) forinstallation at the appliance.

Utility companies can use the technique just described to gain access totheir meter devices remotely. The meter devices can be connected to theInternet and accessed by the utility company through the Internet forthe purpose of taking readings, making adjustments, turning off service,etc. Similarly, banks and financial institutions can connect theirfinancial machines, ATM's for example, to the Internet and then remotelycontrol and monitor them from central locations. In general, anyelectrical or electronic device for which remote monitoring and/orcontrol is desired can be connected to the Internet and, preferably, beprovided with a personal page, and thereby accessed remotely byauthorized personnel. Password protection and/or encryption techniquesas known in the art can be used to protect the integrity of suchsystems.

The user creating a buyer request script can, in some embodiments, sendhis/her buying request script out to the Internet in search of other,similar buying request scripts. The buying request script then “joins”together with other scripts to form collective buying groups, hoping toget a better deal by combining with other purchases into a single,larger purchase. Preferably, this is done as follows. The user creates abuyer request script as described above, which is then sent to anaggregation site on the Internet where the combining with similarscripts, if it is to occur, takes place. Software at the aggregationsite scans and analyzes the scripts that have been sent there and,preferably, using Artificial Intelligence techniques identifies scriptsthat are compatible and that can be combined. The software then createsa “super” buying script from the aggregated ones that represents thecombined purchase, once again preferably using Artificial Intelligencetechniques. In alternative embodiments, the combining is not done at acentral aggregation site, but instead software aggregation agentsroaming the Internet and visiting users' personal pages locate and poolcompatible scripts from which super scripts are created. Preferably,super scripts belong to virtual users, “super” users, which are softwareentities that represent the combined interests of the real users whosescripts have been combined. The super scripts then act like ordinaryuser scripts as described above. Once a super script finds a matchingvendor script and the deal is closed, the aggregation software splitsthe purchase among the aggregated buyer request scripts and preferablysends electronic notification to the users whose scripts were combinednotifying them that a match has been found. Vendor scripts can becombined in a similar way in some embodiments. In some embodiments,super scripts themselves can be combined to form “super super scripts,”and so on.

Personal pages can also be used to support online “Requests ForProposals,” (RFP's). The user wishing to solicit proposals creates anRFP, preferably using a high-level scripting language as describedabove, and puts it on his/her personal page. In other embodiments, itcan be created by completing an electronic form. Alternatively, the RFPcan be generated using voice input and/or graphical techniques, or anyother technique known in the art for collecting data from users. Once onthe personal page, the system uses the techniques for finding suitablematches for a user's bidding requirement described above to findappropriate proposals that are compatible with the RFP. Proposals playthe role of vendor scripts described above. In the preferred embodiment,the RFP stays resident on the personal page while roaming vendorsoftware agents traverse the Internet visiting personal pages lookingfor RFP's. A vendor software agent that locates a compatible RFP thensubmits an electronic proposal to the user, preferably by submitting itto the user's personal page. In other embodiments, RFP's roam theInternet and visit selected sites where they encounter vendors' softwareagents. In other embodiments, the RFP's and vendor agents are sent tocentral sites where the matching takes place. In yet other embodiments,the continuously circulating marketplace technique described below canbe used. In general, any technique known in the art for rendezvousingsoftware and/or data entities in a network can be used.

In the preferred embodiment, a central historical archive of RFP's andthe proposals submitted in response to them is maintained on theInternet. (In other embodiments, the historical archive is not storedcentrally, but is distributed across the network, and may even be storedlocally on users' computers. They may even be contained on users'personal pages.) On creating an RFP, the user can, optionally, query thehistorical archive, retrieving similar RFP's along with the proposalssubmitted to them. The user can then use these retrieved proposals andcontact the vendors that submitted them to solicit proposals for his/herRFP. In the preferred embodiment, the query, retrieval, and contactingof vendors for the solicitation of proposals is done automatically bysoftware agents connected with the user's personal page. All techniquesknown in the art for gauging the similarity of scripts can be used todetermine if two RFP's are similar, including but not limited to thecompatibility dictionary technique described above.

Returning to B.R.'s and vendor scripts, in an alternative embodiment,the bidding, purchasing, and matching can be done at a network site ormultiple sites, called here the “marketplace,” which is neither theuser's local computer nor the vendor's site. The marketplace acts as anelectronic market matcher, matching vendors and users. The marketplacedynamically maintains a database of pending users' purchase requests(B.R.'s). Preferably, this database is segmented along item categoriesso that matching vendors and users can be done efficiently and quickly.Vendor electronic representatives are also transmitted to themarketplace.

The marketplace interprets (i.e., executes) each vendor script againsteach purchase request in the appropriate category (or categories) of thedatabase. When a match is found, the marketplace may electronicallyenable the vendor's electronic software representative to contact theuser. This is similar to the feature on dating/matchmaking sites wherethe user can ask the system to notify him/her when a suitable candidateregisters with the site. Alternatively, the marketplace sends electronicmessages to the matched user and vendor indicating that they have beenmatched. Also, vendor scripts can have trigger features, which ask themarketplace to store the script indefinitely or for a limited period oftime and to enable the script (or the vendor) when a matching userrequest is sent to the marketplace. Similarly, the user request can bestored in the marketplace indefinitely or for a limited period of time,on command from the user, and can have triggering features.

FIGS. 20-24 provide further implementation details of this alternativeembodiment. FIG. 20 shows computer processes that are concurrentlyexecuted to match purchasing requirements and vendor scripts.Preferably, these processes are synchronized using wait and signalprimitives. FIG. 21 illustrates the process of processing purchasingrequirements in accordance with user input. Unfulfilled purchases canremain in the system on its activation list. The processing of vendorscripts is performed in a similar manner. (See FIG. 21.) The matching ofpurchasing requests and vendor scripts is illustrated in FIGS. 22 and23. The matching techniques described above may be used for thispurpose. FIG. 24 shows a method for managing the purchasing requests(BR's) activation list. A similar process can be used to manage thevendor script activation list.

An alternate implementation that enables various entities to conductelectronic transactions in a distributed environment is based on theobject-oriented computation model. In this implementation, activeintelligent software “agents” (objects) are instantiated by users, eachagent the carrier of a purchasing requirement and bidding rulethroughout the network. The agents represent the user in his/her questto make purchases. We will call these agents “purchasing agents.”Similarly, vendors instantiate intelligent software agents that carryscripts throughout the network. We will call these agents “vendor scriptagents.” All agents can remain anonymous if their owners wish to remainanonymous.

On instantiation, a purchasing agent is released into the Internet,migrating to sites at which it will meet vendor script agents. Onfinding one another, the bidding rule agent and vendor script agentinvoke methods (functions) within each other to determine if they are acompatible match. When a match is found, both agents report back totheir owners (the user and the vendor) that a match has been found, andthe deal can then be closed between the user and the vendor. The agentscan then be destroyed as the deal is concluded.

The purchasing agents can be relatively passive compared with the vendorscript agents. The purchasing agents can migrate to a marketplace siteand passively wait for vendor script agents to “fly by” and visit them.

Yet another implementation is possible, this one based on a continuallycirculating marketplace. Here, all information on a global basis, orperhaps on an industry basis, is constantly and continually circulatingthroughout the Internet. All bidding rules and all vendor scripts arecontinuously being broadcast and rebroadcast to every server (or perhapsto every local computer) on the Internet. Alternatively, there can betwo separate broadcast streams, one for purchasing requests and one forvendor scripts. Alternatively, only purchasing requests are broadcast.Alternatively, only vendor scripts are broadcast. So a user wishing tomake a purchase inserts his purchasing request into the broadcaststream. Similarly, a vendor with goods and/or services to offer insertshis script into the circulating stream. A user with a purchase to makewrites a request that “pulls down” (i.e., filters) from the circulatingstream of scripts those scripts relevant to his purchase request.Similarly, or perhaps alternatively, the vendor wishing to sell goodsand/or services writes a script that pulls down from the circulatingstream of purchasing requests those requests that are relevant to whatthe vendor is marketing. The pulled down scripts (or purchasingrequests) can then be examined by the user (or vendor) for a match. Ingeneral, any technique known in the art for rendezvousing softwareand/or data entities in a network can be used.

A continually circulating steam of information is a generally usefultechnique that applies beyond the confines of the application justdescribed. An entire network, such as the Internet, for example, can beimplemented using this technique. Preferably connected through highspeed cable or, in other embodiments, through wireless microwavecommunication or through satellite transmissions, the entire informationcontained in the network is continually circulated to each user's localcomputer. Preferably, the information is grouped into page-like units,similar to the technique used in the Internet today where information isorganized into Web pages. The user wishing to access information in thenetwork composes a software filter that executes on his/her localcomputer and extracts from the circulating stream those pages containinginformation he/she is interested in. For example, if the user wishes tosee all pages containing the phrase “American democracy,” then he/shecomposes a filter in an appropriate scripting language indicating thatonly those pages containing the desired phrase are to be extracted.Alternatively, he/she completes an electronic form similar to the wayInternet search engines operate and inserts the phrase “Americandemocracy” into an appropriate field on the form, or uses voice inputtechniques as are known in the art. In general, any technique known inthe art for collecting information from a user can be used. The user'slocal computer then extracts from the circulating stream the desiredpages for presentation to the user. Alternatively, the continuallycirculating stream of information may not be broadcast to each user'slocal computer, but instead may be broadcast to computers to whichuser's local computer's are connected, e.g., servers. In suchembodiments, the user composes filters that are sent to the server andexecute there on the user's behalf. The extracted data is then sent bythe server to the user's local computer. Should a user wish tocommunicate information from his/her local computer to another computerlocated on the network, the user inserts the information into thecirculating stream with an electronic address indicating thedestination. Alternatively, if the user's local computer does not havethe circulating stream sent directly to it, but instead is connected toa server to which the stream is broadcast, then the user sends theinformation to the server for insertion into the circulating stream. Allinter-computer communication (e.g., email, Instant Messages, etc.) canbe done using this technique. A message destined for another computer ispreferably removed from the circulating stream by the receiving computeras it extracts the received message. Alternatively or in addition, thetransmitting computer can remove the message from the stream after acertain amount of time has elapsed or after the message has circulatedthrough the network a certain number of times. Alternatively or inaddition, garbage collecting “scavenger” nodes that prune theinformation stream and remove old and/or expired messages and/or pagesmay be included in the network. In some embodiments, encryptiontechniques as are known in the art can be used to shield unauthorizedaccess and/or manipulation of information from the stream. In someembodiments, the network may include “police” nodes that monitor thenetwork for undesired and/or illegal data, e.g., pornography.

In some embodiments, the circulating stream of information may becomposed of several circulating substreams, not all of which would benecessarily broadcast to every computer on the network. For example,there may be a sports substream, a science substream, a financialsubstream, etc. The substreams may not necessarily be disjoint, i.e.,some information may appear in several substreams. For example, anarticle about grapes may circulate in a wine connoisseurs substream andin an agricultural substream.

The present invention is not to be limited in scope by the specificembodiments described herein. Indeed, various modifications of theinvention in addition to those described herein will become apparent tothose skilled in the art from the foregoing description and accompanyingfigures. Such modifications are intended to fall within the scope of theappended claims. Doubtless numerous other embodiments can be conceivedthat would not depart from the teaching of the present invention whosescope is defined by the following claims.

1-36. (canceled)
 37. A method for facilitating an electronictransaction, comprising: generating a first deal form for a buyer, thefirst deal form including first attribute values; comparing the firstdeal form with a second deal form from a vendor, the second deal formincluding second attribute values to determine whether the first dealform and the second deal form are compatible; and initiating theelectronic transaction in response to determining that the first dealform is compatible with the second deal form.
 38. The method of claim37, further comprising: receiving buying requirements from a buyer;populating the first attribute values of the first deal form based onthe buying requirements.
 39. The method of claim 37, further comprising:receiving the second deal form from the vendor.
 40. The method of claim37, wherein the second attributes values are associated with goods andservices available from the vendor.
 41. The method of claim 39, furthercomprising: translating the first attribute values and the secondattribute values from a high level language to a lower languageequivalent.
 42. A system for facilitating an electronic transaction,comprising: means for generating a first deal form for a buyer, thefirst deal form including first attribute values; means for comparingthe first deal form with a second deal form from a vendor, the seconddeal form including second attribute values to determine whether thefirst deal form and the second deal form are compatible; and means forinitiating the electronic transaction in response to determining thatthe first deal form is compatible with the second deal form.
 43. Thesystem of claim 42, further comprising: means for receiving buyingrequirements from the buyer; means for populating the first attributevalues of the first deal form based on the buying requirements.
 44. Themethod of claim 42, further comprising: means for receiving the seconddeal form from the vendor.
 45. The method of claim 42, wherein thesecond attributes values are associated with goods and servicesavailable from the vendor.
 46. The method of claim 42, furthercomprising: means for translating the first attribute values and thesecond attribute values from a high level language to a lower languageequivalent.
 47. An article of manufacture including a tangiblecomputer-readable medium having instructions stored thereon, that inresponse to execution by a computing device cause the computing deviceto perform operations comprising: generating a first deal form for abuyer, the first deal form including first attribute values; comparingthe first deal form with a second deal form from a vendor, the seconddeal form including second attribute values to determine whether thefirst deal form and the second deal form are compatible; and initiatingthe electronic transaction in response to determining that the firstdeal form is compatible with the second deal form.
 48. The article ofmanufacture of claim 47, wherein the operations further comprise:receiving buying requirements from the buyer; populating the firstattribute values of the first deal form based on the buyingrequirements.
 49. The article of manufacture of claim 47, wherein theoperations further comprise: receiving the second deal form from thevendor.
 50. The article of manufacture of claim 47, wherein the secondattributes values are associated with goods and services available fromthe vendor.
 51. The article of manufacture of claim 47, wherein theoperations further comprise: translating the first attribute values andthe second attribute values from a high level language to a lowerlanguage equivalent.